Encryption mechanisms can be classified into two varieties. First, two parties can agree on a session key and use that session key, SK, for encryption for the duration of the session. That is, the duration of what may be characterized as a continuous or ongoing session. This mechanism is typically used for session oriented communications, for instance between a client and a server, or between a browser and a web server. Here the party sending the first message will generate a fresh session key (SK) that will be used to encrypt all messages during the session using symmetric encryption techniques, and then “envelope” this SK using asymmetric cryptography. For instance, using private/pubic key infrastructure, the encryption can be performed by encrypting the SK using the public key of the other party or entity.
The second mechanism is typically used for storing and forwarding individual communications such as an email or text message. Here the party sending the message (say an email), will generate a fresh session key, or what is better characterized as a single message session key, SMSK, encrypt the message using symmetric encryption techniques, and then “envelope” the message key SMSK for that message using asymmetric cryptography. For instance, using private/pubic key infrastructure, the encryption can be performed by encrypting the SMSK for that message using the public key of the recipient.
Messaging applications, such as texting, fall into the email style store and forward paradigm. That is, there is no continuous session between the two parties. However, using the second mechanism described above to generate a SMSK per text message can be quite costly, particularly in view of the fact that asymmetric cryptography is inherently inefficient. Furthermore, with devices, such as smartphones, it is beneficial to conserve battery power as much as possible. Generating a SMSK per email or text message will often require generating numerous SMSKs over short periods of time, and hence the expenditure of significant battery power that time period.
Accordingly, a need exist for a more efficient mechanism for encrypting text messages.
Whenever end to end encryption, such as what is described above is achieved, it raises the concern that the communications cannot be viewed by a third party. In fact, the main purpose of all types of SKs, including SMSKs, is to ensure that no third party can see the information being communicated. Yet, in practice there are always legitimate third parties who have a legitimate interest in seeing the messages without the consent of either the sender or the intended recipient.
Two commonly accepted requirements essentially define key escrow systems. First the system should provide an authority the ability to access encrypted information without the cooperation of the participants. Second, the “backdoor” inherent in the system should not be usable by an unauthorized third party. Although the additional requirements discussed in the following paragraphs are important, they are not necessarily commonly accepted.
Authorities should have access only to short term session keys, not to long-term user secrets. In most cryptographic systems, each user has a long-term private secret. In public-key cryptography, this would be the user's private key. In a third-party authentication system, this would be the long-term secret shared between the user and the third-party server. For communications security, these long-term private secrets are typically used to negotiate, i.e. secure, a relatively short-lived session key that is exchanged between the parties and in turn is used for encrypting a given session or conversation, i.e. for encrypting the message or messages communicated during the session.
If a legitimate authority seeks to eavesdrop on a conversation, one of two things can happen. One alternative is for the key escrow system to allow the authority to discover the user's long-term private secret, through which the authority can learn the session key for a given conversation and proceed to eavesdrop. Another alternative is for the key escrow system to allow the authority to discover the session key for a particular conversation, but not the long-term private secret. The authority can still eavesdrop successfully, but the long-term private secret is safe.
It will be preferable for key escrow systems to be designed around the latter approach of revealing only short-lived session keys. This is important for several reasons.
First, since the long-term private secret is never revealed to anyone, it can be reused for other functions, such as digital signatures. In systems in which an authority can access this long-term secret, reusing the long-term private secret to generate digital signatures gives the authority the power to forge signatures.
Second, revealing only session keys provides a finer level of granularity of control. For instance, in such systems, one could implement policies such as (i) the authority can eavesdrop on all of John Doe's conversations, except those he has with his wife or lawyer, or (ii) the authority can decrypt all of John Doe's files saved between March 1994 and September 1994, but not files saved before or after those dates.
Escrow systems represent a compromise between an individual's right to privacy and an authority's right to eavesdrop. Revealing session keys—as opposed to long term private secrets—provides more opportunities for compromise. This is because the compromise is not permanent. That is, in systems in which long-term private secrets are revealed, the compromise of the user's secret is permanent. At some point, the user must get a new long term private secret, e.g. a new private key, or if the secret is embedded in a chip in a cellular or smart phone or other smart device, a new chip. On the other hand, revealing session keys does not compromise the long-term integrity of the permanent secret. So, once the period of “legal eavesdropping” is over, the user does not have to be issued a new private key or other type of long term private secret.
A brute force approach to escrow within an end to end encryption mechanism as described above, would be to archive the secret, e.g. the private key, for each user. As described above, this is taking an axe to a problem which requires a chisel. A far more sensible approach would be to escrow only the session keys. Another approach would be to give the power of escrowing the session keys to the server in the cloud that mediates the session key exchange in the first place. This unfortunately results in the compromise of that single service becoming catastrophic.
Accordingly, a need also exist for an improved escrowing technique.
Closely related to encryption and escrow is the concept of digital signatures. Conventional techniques for performing digital signatures have been around for a very long period of time, but are still seldom used. The primary obstacle has to do with the end user complexity which implementations of digital signatures entail. In the meantime however, the use of graphical signatures has grown by leaps and bounds, and consumers are now very accustomed to creating a graphical signature at a check out register in supermarkets and other such retail locations. However, since a graphical signature can be perfectly copied and pasted it lacks the additional assurance that can be provided by digital signatures.
Accordingly, a need also exist for an improved technique for performing digital signatures.